CC: @parkera @phausler

@swift-ci please test

I assume clang is the one emitting this on Windows then? What definition for the struct does it use?

@parkera: correct. It uses unsigned long int (which is going to be 32-bits on LLP64).

struct Block_descriptor {
  unsigned long int reserved;
  unsigned long int size;
  void (*copy_helper)(void *, void *);
  void (*dispose_helper)(void *);
  const char *signature;
  void *layout;
};

Also, note that this change will be ABI compatible on all non-LLP64 targets

@parkera seems like a pretty simple case?

The root of the question is me wondering if the first two values should be 64 bits on LLP64, like they would be on LP64. I suppose that would require an update to clang when targeting Windows. However, when looking at the rest of the source here it doesn't appear to be actually used by the runtime so I guess this is ok.

Sure, we could look at altering the definition in LLP64 since we don't expect there to be many users right now. I think that is beyond the scope of this change and we should discuss that with @rjmccall first.

That's an interesting question. I think the intent of the specification is probably to always get a pointer-sized integer, yes; that is, the reserved field should allow it to be used for a pointer, and the size field should not impose artificial restrictions on the size (even though a > 4GB block literal is pretty clearly impossible given that all block literals with an extended size need to be allocated on the stack).

I think that is a change we can reasonably make, but yeah, it's really up to the libclosure mantainers (CC @gparker42), as well as needing changes to clang and (I think) gcc.

Yes, the intent is uintptr_t. The original author of this code was a classic C89 / LP64 / Unix guy so unsigned long int is how he would have spelled that intent.